Category Archives: End User

SharePoint: News Translations in a Team Site


You may also be interested in: O’Reilly - SharePoint 2010 at Work


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

This example may be interesting for Communication employees in multinational organizations.

What was the problem?

As in many international companies, the company language is English. Most people can read that, but general survey feedback showed that employees would really appreciate to read important business news in their own language.

So the Communications team decided that those messages would be translated into 14 different languages. Hiring an external translation agency was easy, but how to handle all those primary, draft and final documents (some of which were unintelligible for the Comms team) without getting confused?

What is the solution?

We set up an external Team Site with 2 libraries:

  • One library for the primary document, in English. The agency set an Alert (Added Documents, Immediately) so they know when they have to start translating.
  • One library for the translations. The agency uploads the translations to this library, using a special naming convention, adding the language as metadata, so we can group the documents by language.
    Designated local employees then check the translations, making sure that the texts fit country and company culture. These employees have set an Alert (Added Items, Daily) so they know when they have to correct a document. They can make changes online. When a translation is OK, a box is “final” is checked.
    (Since the Alert can not distinguish beteen languages, we suggest a Daily e-mail to avoid getting too many irrelevant emails)
  • Communications has also set an Alert to the Translations library, to monitor progress. (All Changes, Daily)

All documents with”the “final” checkbox are made visible to employees in special views by language.

(for advanced users: in a separate Team Site we have created one Web Part Page per language, and “project” the documents, filtered by language, on that page using Corasworks)

What are the benefits?

This setup is not ideal, since the information is still hidden in documents and there are no Alerts per language. A truely online process with targeted news in the correct translation on people’s Homepage would be better, but that is not available at this moment. Still, this setup does help to streamline the process:

  • All documents are in one place.
  • Notification emails that “you have work to do” are being sent automatically.
  • Documents are properly tagged with metadata.
  • No confusion with loads of documents in individual emails.
  • The data can be used for KPI’s, such as turnaround time, learning curve of the translation agency, and projected costs.

Another example of how some thinking and experience with SharePoint can solve those all-too-common business problems!

This is the Source library, containing the original English document:

2013-11-03-EmployeeDirectory-01.png
Source Library, containing the original English documents.

And this is the Target Library, where the translations can be uploaded.

2013-11-03-EmployeeDirectory-02.png
Library for the translated documents

SharePoint: News Translations in a Team Site


You may also be interested in: O’Reilly - SharePoint 2010 at Work


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

This example may be interesting for Communication employees in multinational organizations.

What was the problem?

As in many international companies, the company language is English. Most people can read that, but general survey feedback showed that employees would really appreciate to read important business news in their own language.

So the Communications team decided that those messages would be translated into 14 different languages. Hiring an external translation agency was easy, but how to handle all those primary, draft and final documents (some of which were unintelligible for the Comms team) without getting confused?

What is the solution?

We set up an external Team Site with 2 libraries:

  • One library for the primary document, in English. The agency set an Alert (Added Documents, Immediately) so they know when they have to start translating.
  • One library for the translations. The agency uploads the translations to this library, using a special naming convention, adding the language as metadata, so we can group the documents by language.
    Designated local employees then check the translations, making sure that the texts fit country and company culture. These employees have set an Alert (Added Items, Daily) so they know when they have to correct a document. They can make changes online. When a translation is OK, a box is “final” is checked.
    (Since the Alert can not distinguish beteen languages, we suggest a Daily e-mail to avoid getting too many irrelevant emails)
  • Communications has also set an Alert to the Translations library, to monitor progress. (All Changes, Daily)

All documents with”the “final” checkbox are made visible to employees in special views by language.

(for advanced users: in a separate Team Site we have created one Web Part Page per language, and “project” the documents, filtered by language, on that page using Corasworks)

What are the benefits?

This setup is not ideal, since the information is still hidden in documents and there are no Alerts per language. A truely online process with targeted news in the correct translation on people’s Homepage would be better, but that is not available at this moment. Still, this setup does help to streamline the process:

  • All documents are in one place.
  • Notification emails that “you have work to do” are being sent automatically.
  • Documents are properly tagged with metadata.
  • No confusion with loads of documents in individual emails.
  • The data can be used for KPI’s, such as turnaround time, learning curve of the translation agency, and projected costs.

Another example of how some thinking and experience with SharePoint can solve those all-too-common business problems!

This is the Source library, containing the original English document:

2013-11-03-EmployeeDirectory-01.png
Source Library, containing the original English documents.

And this is the Target Library, where the translations can be uploaded.

2013-11-03-EmployeeDirectory-02.png
Library for the translated documents

SharePoint: News Translations in a Team Site


You may also be interested in: O’Reilly - SharePoint 2010 at Work


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

This example may be interesting for Communication employees in multinational organizations.

What was the problem?

As in many international companies, the company language is English. Most people can read that, but general survey feedback showed that employees would really appreciate to read important business news in their own language.

So the Communications team decided that those messages would be translated into 14 different languages. Hiring an external translation agency was easy, but how to handle all those primary, draft and final documents (some of which were unintelligible for the Comms team) without getting confused?

What is the solution?

We set up an external Team Site with 2 libraries:

  • One library for the primary document, in English. The agency set an Alert (Added Documents, Immediately) so they know when they have to start translating.
  • One library for the translations. The agency uploads the translations to this library, using a special naming convention, adding the language as metadata, so we can group the documents by language.
    Designated local employees then check the translations, making sure that the texts fit country and company culture. These employees have set an Alert (Added Items, Daily) so they know when they have to correct a document. They can make changes online. When a translation is OK, a box is “final” is checked.
    (Since the Alert can not distinguish beteen languages, we suggest a Daily e-mail to avoid getting too many irrelevant emails)
  • Communications has also set an Alert to the Translations library, to monitor progress. (All Changes, Daily)

All documents with”the “final” checkbox are made visible to employees in special views by language.

(for advanced users: in a separate Team Site we have created one Web Part Page per language, and “project” the documents, filtered by language, on that page using Corasworks)

What are the benefits?

This setup is not ideal, since the information is still hidden in documents and there are no Alerts per language. A truely online process with targeted news in the correct translation on people’s Homepage would be better, but that is not available at this moment. Still, this setup does help to streamline the process:

  • All documents are in one place.
  • Notification emails that “you have work to do” are being sent automatically.
  • Documents are properly tagged with metadata.
  • No confusion with loads of documents in individual emails.
  • The data can be used for KPI’s, such as turnaround time, learning curve of the translation agency, and projected costs.

Another example of how some thinking and experience with SharePoint can solve those all-too-common business problems!

This is the Source library, containing the original English document:

2013-11-03-EmployeeDirectory-01.png
Source Library, containing the original English documents.

And this is the Target Library, where the translations can be uploaded.

2013-11-03-EmployeeDirectory-02.png
Library for the translated documents

SharePoint: News Translations in a Team Site


You may also be interested in: O’Reilly - SharePoint 2010 at Work


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

This example may be interesting for Communication employees in multinational organizations.

What was the problem?

As in many international companies, the company language is English. Most people can read that, but general survey feedback showed that employees would really appreciate to read important business news in their own language.

So the Communications team decided that those messages would be translated into 14 different languages. Hiring an external translation agency was easy, but how to handle all those primary, draft and final documents (some of which were unintelligible for the Comms team) without getting confused?

What is the solution?

We set up an external Team Site with 2 libraries:

  • One library for the primary document, in English. The agency set an Alert (Added Documents, Immediately) so they know when they have to start translating.
  • One library for the translations. The agency uploads the translations to this library, using a special naming convention, adding the language as metadata, so we can group the documents by language.
    Designated local employees then check the translations, making sure that the texts fit country and company culture. These employees have set an Alert (Added Items, Daily) so they know when they have to correct a document. They can make changes online. When a translation is OK, a box is “final” is checked.
    (Since the Alert can not distinguish beteen languages, we suggest a Daily e-mail to avoid getting too many irrelevant emails)
  • Communications has also set an Alert to the Translations library, to monitor progress. (All Changes, Daily)

All documents with”the “final” checkbox are made visible to employees in special views by language.

(for advanced users: in a separate Team Site we have created one Web Part Page per language, and “project” the documents, filtered by language, on that page using Corasworks)

What are the benefits?

This setup is not ideal, since the information is still hidden in documents and there are no Alerts per language. A truely online process with targeted news in the correct translation on people’s Homepage would be better, but that is not available at this moment. Still, this setup does help to streamline the process:

  • All documents are in one place.
  • Notification emails that “you have work to do” are being sent automatically.
  • Documents are properly tagged with metadata.
  • No confusion with loads of documents in individual emails.
  • The data can be used for KPI’s, such as turnaround time, learning curve of the translation agency, and projected costs.

Another example of how some thinking and experience with SharePoint can solve those all-too-common business problems!

This is the Source library, containing the original English document:

2013-11-03-EmployeeDirectory-01.png
Source Library, containing the original English documents.

And this is the Target Library, where the translations can be uploaded.

2013-11-03-EmployeeDirectory-02.png
Library for the translated documents

SharePoint: Employee Directory and a Team Site


You may also be interested in: fpweb.net


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

Maria was one of our most dedicated administrators of the Employee Directory. She was working in one of our larger locations, and she was very motivated to keep her part of the Directory up-to-date. If you saw an employee profile from her location, you could trust it would be 100% accurate. Being that dedicated also took her a lot of time. So she asked me if there was a solution to her chasing everyone for the correct information.

What was the problem?

The Employee Directory was not (yet) connected to another system, so it had to be updated manually.

Maria’s location included many manufacturing and marketing employees, who changed jobs frequently. She received information about changes from various channels: e-mail, documents (via e-mail or snail mail). chat, fax, telephone and visits to her desk. Hardly anyone provided the full set of details needed, so she always had to ask people for the additional information.

What is the solution?

We set up a simple SharePoint custom list for her, in local language. We used pre-filled Choice or Lookup columns where possible, to make it easy for the requester and guarantee consistent information. We made two views: “In Progress” (default), and “Completed”.

Maria set an Alert (Added Items, Daily Summary) so every morning she knew the changes she had to make.

When she had made the required change for one person, she would tick the box “completed” in the request and the item would move to the “Completed” view. This way she always knew which requests were still waiting for her, and she also had an archive of finished requests.

What are the benefits?

  • Maria saved time, because the information she received was complete. There was no longer any need to chase someone for missing information.
  • The business was happy, because the changes were processed faster, making the Directory more accurate and trustworthy. (Of course they grumbled a little when they were confronted with a new process, but Maria sold the benefits very well – and simply refused to process any request via another channel2013-10-27-EmployeeDirectory-01.gif)
  • Many employees were now working in SharePoint lists, and this sparked ideas for other applications.
  • This was a very generic process which could be replicated to other locations easily. So even though this project did not generate many financial benefits, the project had a high priority because it was a very reproducible solution.

Another inefficient process was streamlined with little effort!

Please find below some re-created screenshots.

2013-10-27-EmployeeDirectory-02.gif

2013-10-27-EmployeeDirectory-03.gif

SharePoint: Employee Directory and a Team Site


You may also be interested in: fpweb.net


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

Maria was one of our most dedicated administrators of the Employee Directory. She was working in one of our larger locations, and she was very motivated to keep her part of the Directory up-to-date. If you saw an employee profile from her location, you could trust it would be 100% accurate. Being that dedicated also took her a lot of time. So she asked me if there was a solution to her chasing everyone for the correct information.

What was the problem?

The Employee Directory was not (yet) connected to another system, so it had to be updated manually.

Maria’s location included many manufacturing and marketing employees, who changed jobs frequently. She received information about changes from various channels: e-mail, documents (via e-mail or snail mail). chat, fax, telephone and visits to her desk. Hardly anyone provided the full set of details needed, so she always had to ask people for the additional information.

What is the solution?

We set up a simple SharePoint custom list for her, in local language. We used pre-filled Choice or Lookup columns where possible, to make it easy for the requester and guarantee consistent information. We made two views: “In Progress” (default), and “Completed”.

Maria set an Alert (Added Items, Daily Summary) so every morning she knew the changes she had to make.

When she had made the required change for one person, she would tick the box “completed” in the request and the item would move to the “Completed” view. This way she always knew which requests were still waiting for her, and she also had an archive of finished requests.

What are the benefits?

  • Maria saved time, because the information she received was complete. There was no longer any need to chase someone for missing information.
  • The business was happy, because the changes were processed faster, making the Directory more accurate and trustworthy. (Of course they grumbled a little when they were confronted with a new process, but Maria sold the benefits very well – and simply refused to process any request via another channel2013-10-27-EmployeeDirectory-01.gif)
  • Many employees were now working in SharePoint lists, and this sparked ideas for other applications.
  • This was a very generic process which could be replicated to other locations easily. So even though this project did not generate many financial benefits, the project had a high priority because it was a very reproducible solution.

Another inefficient process was streamlined with little effort!

Please find below some re-created screenshots.

2013-10-27-EmployeeDirectory-02.gif

2013-10-27-EmployeeDirectory-03.gif

SharePoint: Employee Directory and a Team Site


You may also be interested in: fpweb.net


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

Maria was one of our most dedicated administrators of the Employee Directory. She was working in one of our larger locations, and she was very motivated to keep her part of the Directory up-to-date. If you saw an employee profile from her location, you could trust it would be 100% accurate. Being that dedicated also took her a lot of time. So she asked me if there was a solution to her chasing everyone for the correct information.

What was the problem?

The Employee Directory was not (yet) connected to another system, so it had to be updated manually.

Maria’s location included many manufacturing and marketing employees, who changed jobs frequently. She received information about changes from various channels: e-mail, documents (via e-mail or snail mail). chat, fax, telephone and visits to her desk. Hardly anyone provided the full set of details needed, so she always had to ask people for the additional information.

What is the solution?

We set up a simple SharePoint custom list for her, in local language. We used pre-filled Choice or Lookup columns where possible, to make it easy for the requester and guarantee consistent information. We made two views: “In Progress” (default), and “Completed”.

Maria set an Alert (Added Items, Daily Summary) so every morning she knew the changes she had to make.

When she had made the required change for one person, she would tick the box “completed” in the request and the item would move to the “Completed” view. This way she always knew which requests were still waiting for her, and she also had an archive of finished requests.

What are the benefits?

  • Maria saved time, because the information she received was complete. There was no longer any need to chase someone for missing information.
  • The business was happy, because the changes were processed faster, making the Directory more accurate and trustworthy. (Of course they grumbled a little when they were confronted with a new process, but Maria sold the benefits very well – and simply refused to process any request via another channel2013-10-27-EmployeeDirectory-01.gif)
  • Many employees were now working in SharePoint lists, and this sparked ideas for other applications.
  • This was a very generic process which could be replicated to other locations easily. So even though this project did not generate many financial benefits, the project had a high priority because it was a very reproducible solution.

Another inefficient process was streamlined with little effort!

Please find below some re-created screenshots.

2013-10-27-EmployeeDirectory-02.gif

2013-10-27-EmployeeDirectory-03.gif

SharePoint: Employee Directory and a Team Site


You may also be interested in: fpweb.net


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

Maria was one of our most dedicated administrators of the Employee Directory. She was working in one of our larger locations, and she was very motivated to keep her part of the Directory up-to-date. If you saw an employee profile from her location, you could trust it would be 100% accurate. Being that dedicated also took her a lot of time. So she asked me if there was a solution to her chasing everyone for the correct information.

What was the problem?

The Employee Directory was not (yet) connected to another system, so it had to be updated manually.

Maria’s location included many manufacturing and marketing employees, who changed jobs frequently. She received information about changes from various channels: e-mail, documents (via e-mail or snail mail). chat, fax, telephone and visits to her desk. Hardly anyone provided the full set of details needed, so she always had to ask people for the additional information.

What is the solution?

We set up a simple SharePoint custom list for her, in local language. We used pre-filled Choice or Lookup columns where possible, to make it easy for the requester and guarantee consistent information. We made two views: “In Progress” (default), and “Completed”.

Maria set an Alert (Added Items, Daily Summary) so every morning she knew the changes she had to make.

When she had made the required change for one person, she would tick the box “completed” in the request and the item would move to the “Completed” view. This way she always knew which requests were still waiting for her, and she also had an archive of finished requests.

What are the benefits?

  • Maria saved time, because the information she received was complete. There was no longer any need to chase someone for missing information.
  • The business was happy, because the changes were processed faster, making the Directory more accurate and trustworthy. (Of course they grumbled a little when they were confronted with a new process, but Maria sold the benefits very well – and simply refused to process any request via another channel2013-10-27-EmployeeDirectory-01.gif)
  • Many employees were now working in SharePoint lists, and this sparked ideas for other applications.
  • This was a very generic process which could be replicated to other locations easily. So even though this project did not generate many financial benefits, the project had a high priority because it was a very reproducible solution.

Another inefficient process was streamlined with little effort!

Please find below some re-created screenshots.

2013-10-27-EmployeeDirectory-02.gif

2013-10-27-EmployeeDirectory-03.gif

SharePoint Online Website Examples


You may also be interested in: O’Reilly - SharePoint 2010 at Work


 

Editor’s note: Contributor Chris Clark is the Marketing Manager for Creative Sharepoint. Follow him @chrisclark005

SharePoint Online, a component of Microsoft’s Office 365 suite, provides subscribing organisations with public-facing website functionality. This type of SharePoint public-facing website lacks the full feature set of SharePoint, but is perfectly adequate for websites with basic functionality (not necessarily small or low-traffic sites).

We were recently approached to deliver 2 such websites for a client (N.B. as an educational organisation they were eligible for the A2 Office 365 Plan, meaning their SharePoint Online website licensing and hosting was completely free)

Both of the SharePoint Online websites can be viewed here:

http://www.councilofhealthcarescience.ac.uk/
http://www.pharmacyschoolscouncil.ac.uk/

In this blog post we will give a brief overview of the two websites, exploring:

  • SharePoint Online Website Author Requirements (content management and analytics)
  • SharePoint Online Website Visitor Requirements (user experience and accessibility)
  • SharePoint Online Website Features Leveraged (blog site, list apps and library apps)

SharePoint Online Website Author Requirements

A public-facing website can have all the design and functionality in the world thrown at it, but if the content is not relevant or up-to-date then it is unlikely to have a lasting effect. For that reason, the key requirements from a website author’s perspective were easy content management and the ability to analyse site performance.

Content Management

As the organisation’s marketing team have no internal IT support, it was crucial that the content of both sites could be managed by non-technical authors. The content on the websites, which needs regular updating, includes:

  • Rich text, including videos embedded from YouTube and other sources
  • Links to other pages and external sites
  • Documents (particularly Word and PDF)

2013-10-22-SharePointOnline-01.png
SharePoint Online websites allow videos to be surfaced directly from YouTube using the ‘Embed’ tool

In addition to creating and editing pages independently of IT, the website authors also need to be able to optimise the site for search engines (SEO) without having to edit code.

2013-10-22-SharePointOnline-02.png
SharePoint Online websites allow SEO properties to be changed through a modal in the ribbon

Analytics

Finally, website authors need to track the performance of the websites using Google Analytics. As the code snippet for Google Analytics (the code that allows authors to track websites) can change without notice, website authors also require a way to update this without going into HTML.

2013-10-22-SharePointOnline-03.png
The SharePoint Online ‘Web Analytics App’ (freely available) allows authors to change Google Analytics snippets without touching code

SharePoint Online Website Visitor Requirements

User Experience

Website visitors need a simple, modern look and feel that helped them easily find the content they needed, whilst conveying the organisation’s existing brand guidelines.

2013-10-22-SharePointOnline-04.png
SharePoint Online themes provide the whole website a consistent look and feel whilst custom CSS can be used to enhance specific page elements

Accessibility

As well as looking good, it is also important that the websites meet accessibility standards (specifically being AA compliant). Whilst underlying elements of Office 365 may compromise accessibility, additional code is able to meet the rigorous standards.

SharePoint Online Website Features Leveraged

As I mentioned in the introduction, the SharePoint Online public-facing website lacks the full feature set of SharePoint. Nethertheless, it provides more than enough functionality for many website projects. Here we will look at three areas of functionality in particular; the blog site, list apps and library apps.

Blog Site

The SharePoint Online blog site enables content authors to publish rich text blogs from either the browser or Word. Once published, blogs are automatically categorised and made available to website visitors. The latest blogs are surfaced on the homepage and visitors can choose to follow via RSS, comment with a Facebook account and share content via email.

2013-10-22-SharePointOnline-05.png
Publishing a new blog through a rich text editor, as viewed by a website author

2013-10-22-SharePointOnline-06.png
A new blog post, as viewed by a website visitor

List Apps

List Apps enable content to be stored, as the name suggests, in lists, and then surfaced on various website pages via ‘app parts’. Adding new content to lists is done through simple forms, meaning that pages with these ‘app parts’ can be updated without the use of code.

2013-10-22-SharePointOnline-07.png
Adding a new FAQ through a form, as viewed by a website author

2013-10-22-SharePointOnline-08.png
A list of FAQs, surfaced through an ‘app part’, as viewed by a website visitor

Library Apps

Similarly to list apps, library apps allow content in document format to be stored in libraries and then surfaced on pages via ‘app parts’, once again avoiding the need for editing in HTML.

2013-10-22-SharePointOnline-09.png
Adding a document by dragging-and-dropping into a library, as viewed by a website author

2013-10-22-SharePointOnline-10.png
A list of downloadable documents, as viewed by a website visitor

Conclusion

As you can see, despite the functional limitations of SharePoint Online public-facing websites, they can be more than capable of delivering an impressive authoring and visiting experience. In particular, they can:

  • Streamline content management, reducing dependency on IT
  • Be easily optimised for search engine performance
  • Integrate industry standard analytics
  • and finally, provide an engaging (and accessible) user experience to website visitors

SharePoint Online Website Examples


You may also be interested in: O’Reilly - SharePoint 2010 at Work


 

Editor’s note: Contributor Chris Clark is the Marketing Manager for Creative Sharepoint. Follow him @chrisclark005

SharePoint Online, a component of Microsoft’s Office 365 suite, provides subscribing organisations with public-facing website functionality. This type of SharePoint public-facing website lacks the full feature set of SharePoint, but is perfectly adequate for websites with basic functionality (not necessarily small or low-traffic sites).

We were recently approached to deliver 2 such websites for a client (N.B. as an educational organisation they were eligible for the A2 Office 365 Plan, meaning their SharePoint Online website licensing and hosting was completely free)

Both of the SharePoint Online websites can be viewed here:

http://www.councilofhealthcarescience.ac.uk/
http://www.pharmacyschoolscouncil.ac.uk/

In this blog post we will give a brief overview of the two websites, exploring:

  • SharePoint Online Website Author Requirements (content management and analytics)
  • SharePoint Online Website Visitor Requirements (user experience and accessibility)
  • SharePoint Online Website Features Leveraged (blog site, list apps and library apps)

SharePoint Online Website Author Requirements

A public-facing website can have all the design and functionality in the world thrown at it, but if the content is not relevant or up-to-date then it is unlikely to have a lasting effect. For that reason, the key requirements from a website author’s perspective were easy content management and the ability to analyse site performance.

Content Management

As the organisation’s marketing team have no internal IT support, it was crucial that the content of both sites could be managed by non-technical authors. The content on the websites, which needs regular updating, includes:

  • Rich text, including videos embedded from YouTube and other sources
  • Links to other pages and external sites
  • Documents (particularly Word and PDF)

2013-10-22-SharePointOnline-01.png
SharePoint Online websites allow videos to be surfaced directly from YouTube using the ‘Embed’ tool

In addition to creating and editing pages independently of IT, the website authors also need to be able to optimise the site for search engines (SEO) without having to edit code.

2013-10-22-SharePointOnline-02.png
SharePoint Online websites allow SEO properties to be changed through a modal in the ribbon

Analytics

Finally, website authors need to track the performance of the websites using Google Analytics. As the code snippet for Google Analytics (the code that allows authors to track websites) can change without notice, website authors also require a way to update this without going into HTML.

2013-10-22-SharePointOnline-03.png
The SharePoint Online ‘Web Analytics App’ (freely available) allows authors to change Google Analytics snippets without touching code

SharePoint Online Website Visitor Requirements

User Experience

Website visitors need a simple, modern look and feel that helped them easily find the content they needed, whilst conveying the organisation’s existing brand guidelines.

2013-10-22-SharePointOnline-04.png
SharePoint Online themes provide the whole website a consistent look and feel whilst custom CSS can be used to enhance specific page elements

Accessibility

As well as looking good, it is also important that the websites meet accessibility standards (specifically being AA compliant). Whilst underlying elements of Office 365 may compromise accessibility, additional code is able to meet the rigorous standards.

SharePoint Online Website Features Leveraged

As I mentioned in the introduction, the SharePoint Online public-facing website lacks the full feature set of SharePoint. Nethertheless, it provides more than enough functionality for many website projects. Here we will look at three areas of functionality in particular; the blog site, list apps and library apps.

Blog Site

The SharePoint Online blog site enables content authors to publish rich text blogs from either the browser or Word. Once published, blogs are automatically categorised and made available to website visitors. The latest blogs are surfaced on the homepage and visitors can choose to follow via RSS, comment with a Facebook account and share content via email.

2013-10-22-SharePointOnline-05.png
Publishing a new blog through a rich text editor, as viewed by a website author

2013-10-22-SharePointOnline-06.png
A new blog post, as viewed by a website visitor

List Apps

List Apps enable content to be stored, as the name suggests, in lists, and then surfaced on various website pages via ‘app parts’. Adding new content to lists is done through simple forms, meaning that pages with these ‘app parts’ can be updated without the use of code.

2013-10-22-SharePointOnline-07.png
Adding a new FAQ through a form, as viewed by a website author

2013-10-22-SharePointOnline-08.png
A list of FAQs, surfaced through an ‘app part’, as viewed by a website visitor

Library Apps

Similarly to list apps, library apps allow content in document format to be stored in libraries and then surfaced on pages via ‘app parts’, once again avoiding the need for editing in HTML.

2013-10-22-SharePointOnline-09.png
Adding a document by dragging-and-dropping into a library, as viewed by a website author

2013-10-22-SharePointOnline-10.png
A list of downloadable documents, as viewed by a website visitor

Conclusion

As you can see, despite the functional limitations of SharePoint Online public-facing websites, they can be more than capable of delivering an impressive authoring and visiting experience. In particular, they can:

  • Streamline content management, reducing dependency on IT
  • Be easily optimised for search engine performance
  • Integrate industry standard analytics
  • and finally, provide an engaging (and accessible) user experience to website visitors