A few weeks ago I entered a competition hosted by End User SharePoint where the challenge was to build an RSS reader on SharePoint 2010 in a week. At the end of the week long coding sprint, the judges provide their critic of the solution, which is then turned over to the public to vote for the best implementation and declare the winner. You can get to a demo of all the solutions as well as the voting results HERE. It was allot of fun and although my solution was not really liked by the public (I got last place), I figure I would still make it available, case others want to see how I implemented certain features.
Here is a demo of what the solution looks like:
My solution was implemented all client side with a little help from jQuery, jQuery UI, SPServices and Google’s Feed API at its core. The design I went with was one that would focus the entire page primarily on browsing and reading the RSS stories. I implemented it with a two-pane approach, where the left side of the page, the first location where eyes focus on, is the reading area , and I used the right pane for navigation. Here are the features you will find:
- Always Accessible Navigation
The navigation pane contains a scrollable list of all the feeds. Clicking an individual feed will display its stories on the left pane. It also has a button for displaying all stories from all feeds (sorted by story published date) and a Dashboard area that scrolls through the top headlines. The cool thing here (in my opinion) is that as the user scrolls down through the list of stories in the feed, this pane will switch to static (or sticky) so that it is always accessible to the reader.
- Infinite Scroll
When viewing the stories from each feed (or all feeds), only the headlines are displayed; clicking individual headlines will expand the story and display as much information as provided by the feed. This area of the page (the left pane, or the reading area) also implements an “infinite scroll” approach so only a few feeds are shown at a time, and as the user scrolls down and starts to reach the end of the page, the next page of stories is loaded. The user is never aware that additional stories are getting loaded in the background; they can just continue to scroll.
- Single Page Application
The entire application works in one page. The Add, Delete or Edit feeds are all handled without having to refresh the page or load a different page.
- Dashboard and Favorites
The focused area, upon accessing the reader, is the Dashboard. This area contains a scroll through the top 40 stories (sorted by date) across all of the user’s feeds. It also display an area called Favorites that scrolls through the top 10 story headlines from individual Feeds that one may follow more closely than others. It is meant to give you a quick view into what matters most to the individual reader.
- Support for Multiple Users
The application can support multiple users. It stores feeds and preferences by user ID, thus one installation can support multiple users through out a team or organization.
The only things I have changed from what was done for the competition is 1) the removal of the Twitter API files (they were dragging down user experience performance), 2) support for an anonymous SharePoint configuration, and 3) the addition of “installation” code, which will create the needed Lists on first time access.
Features that never made it due to time (remember: this was a week long effort):
- Keep user settings on what stories have been read and which ones have not. Those that were already read, would be slightly faded out or optionally hidden from view.
- Export and Import
- Higher use of visuals (Site Icons, Story images, etc)
- Preserve Context via URL hash
- Bookmark individual stories
- Keyboard navigation
- Share story via email to other SharePoint Users (Pick user (using this plugin), then have a workflow send them email with the story)
As you can see, I had big plans for this application.
Like I mentioned earlier, this solution is implemented all client side and can quickly be installed on a site by adding a Content Editor webpart to a page. As implemented, this is a SharePoint 2010 solution and has been tested with full page configuration only. The following instruction can also be found in README.txt file found in the zip file:
- Extract the zip file to a temporary folder
- Copy the ‘src’ folder to a Document Library under the desired Site
(tip: use Window Explorer to quickly achieve this task.)
- Using the Browser, navigate to the ‘src’ folder that was copied to SharePoint, right click the file ‘main.html’ and choose (depending on your browser) ‘Copy Link Location’ or ‘Copy Shortcut’. The URL will be needed in step 6a below.
- Create a new WebPart Page (example: rssReader.aspx) using the following settings:
- Type: Web Part Page
- Layout Template: Full Page, Vertical
- Access the WebPart Page created in the prior step and add a new Content Editor webpart to it.
- Click the ‘Content Editor Web Part Menu’ (down arrow at the top-right hand corner of the webpart area) and select ‘Edit Web Part’. From Right panel displayed, set the following:
- Under ‘Content Link’ past the URL to the ‘main.html’ file found under the src folder that was copied to the Document Library
- Under ‘Appearance’, set ‘Chrome Type’ to ‘None’
- Click OK on the Web Part Editor to save your changes
- Stop Editing The Web Part Page
MD5 SUM: 2eba881f9b9147b467b85f09ac3fd57d