Creating a Portal
June 18, 2008
Back in mid October (2007) we started talking seriously about the idea of creating a web based portal solution for Asbury Theological Seminary. In January we actively started development and design of that Portal system and June 3rd, 2008 marked the first stage of the roll out of the system we call “OneATS”.
The video was supposed to be here, if you’re not seeing it you may want to check to make sure your Flash player is up to date and you have JavaScript on.
Maybe I should start with an explanation as to what the term “Portal” meant to us throughout the development process since there are a variety of different definitions explaining what a portal should be or do. To some people a portal is an interactive environment like iGoogle or a Yahoo homepage, to others a portal is a system that delivers particular information like you would see when interacting with an academic information system.
At first the idea of a portal was presented as a way to connect all our academic information together under one login. It was a great idea but after some conversation we wanted to take it a step further, to give the users something that they could actually use in daily life apart from receiving academic records and other “Asbury things.”
So we started working with the concept and in less than 6 months it evolved into a functioning web application. But what does it do exactly?
When the user logs in to the system for the first time they are presented with a nearly blank slate of a page. There are only a few required blocks of content, and other than those the user has the option to add any number of modules to their layout. After creating a customized layout it will then be presented to them at each login. Some of the module options include:
- A variety of news feeds from around the world
- Unlimited custom user defined RSS feeds
- Live video from chapels
- Various television channels
- Random quotes from various authors
- Jokes
- NASA Photo of the day
- Bible Search
- Local Weather
Setting up the layout of a user’s homepage is accomplished through an interactive interface which was put together with PHP and jQuery.

Along with the general modules there are some other customizable sections of the portal. One of the features that I’m really proud of is the status module. That particular module allows others to know what you’re up to at any given time. There’s an extensive set of customization options allowing for groups and private notifications. It’s a lot like Twitter in some ways, only created with the goals of Asbury Seminary in mind.

Forums
We talked a lot about how the community interaction of OneATS should happen, and what software should be involved in the process. We tossed around a lot of ideas but nothing really fit the bill, nothing that we wouldn’t have to put a lot of time into making function within our current setup. Active directory played a big part of the equation, and our usage of the Central Authentication System (CAS) was our other concern. I felt that it would be easier to write a forum solution into OneATS than try to “super glue” a pre-made piece of software onto the side and manage them separately. That of course is a very simplified explanation, if you want more of my reasoning I’d be happy to explain.
Anyway, the forum piece of OneATS is specifically based on our needs at Asbury. If a particular department or group within the Seminary needs to allow topics to be posted between our multiple campuses a colored indicator identifies the campus associated with that message. Each instance of the forum can be made fully featured, read-only, public or small group. All of that is managed by connection to Active Directory, so the administrators of OneATS don’t really need to manage individual users, instead it takes our natural organizational structure and applies it.

Many of you are probably familiar with the idea of web forums, but in a way we needed to break that to make it function for us. Whereas a typical forum section of a website has a space to converse and reply in a linear format, we wanted to leave that open to user interpretation. So as the person creates each topic they have the choice to create: a discussion topic, a shared document, an announcement or a topic for voting. (Voting is yet to be released at this moment.)

Discussion Topic
This is what you would typically see in a regular web forum, someone creates a topic and the other users reply in a linear format.
Shared Document
Though not as fully featured as a Word document, a shared document is a topic that can be edited by multiple users. This is good for things like signup sheets and checklists.
Announcements
In an academic institution there are plenty of times when someone needs to say something that shouldn’t have an option for a response, this was built to accommodate that need.
Voting
This will allow the users the ability to vote in a number of different ways, I’d rather not say too much about it at the moment because, as I said, this feature hasn’t been rolled out yet.
RSS Feeds
At this point in the evolution of technology RSS feeds are everywhere. Unfortunately not everyone has a RSS reader, nor do they necessarily know how to use it if they have one. As a result I wanted to enable users to connect with as many RSS feeds as they would like, and I wanted them to be able to do so with as little difficulty or technological language as possible.
Besides the ability to subscribe to external RSS feeds, OneATS is able to produce its own feeds. Obviously there’s a consideration in that some of the feeds could potentially syndicate internal or private information. The “Master Feed” is an example of that, it (optionally) publishes everything that happens in OneATS concerning each individual user. I came up with an alternative to the privatized RSS option and will probably do a writeup on that in the future. It’s also worth noting that individuals can turn off their Master Feed if they don’t like the security risk. (Rather they can turn it on since it’s off by default.)
Selectable Column Layout
Screen sizes and user preferences differ and so I wanted to allow users the option to select how many columns they want to display in their personal layout. The current options are three columns, four columns and one column. The four column layout is great for people with larger screens, three column is the most versatile and the one column layout is particularly useful for people on smaller screens and mobile devices.

Style and Themes
Everyone has a preference when it comes to aesthetics, color, font style (serif fonts, sans-serif fonts or mixed fonts) and font size. In OneATS you can choose all of that yourself, and when you set your preference in OneATS it stays with you when it is reasonably able to do so. (Some of the systems are so far removed from OneATS that it’s not really possible to replicate all of the user preferences, so a nice general standard was chosen in those cases.) Soon I would like to allow the individual users to select all of the elements of their color scheme rather than one of my pre-created themes.


GMail Integration
Many people use GMail as their main email account and with that in mind I wanted those that would like the option to be able to connect with their GMail accounts from within OneATS. With that in place the user won’t necessarily have to keep GMail open in another tab, they can just watch the incoming information until they receive an email and need to login.
Groups
Everyone has the option of creating an unlimited number of groups from your contacts in OneATS. From there when a user changes their status they have the option to allow only a particular group to see it or make it public (or private). There will be more integration with this feature in the future but for now it’s somewhat limited.

In the Future
I have a ton of features that will eventually show up on OneATS, some of them behind the scenes while others are forefront. At some point it’s going to be difficult to provide a certain amount of extensible features and so my goal is to tie into other API’s to deliver information that our users interact with elsewhere. In that, however, I don’t want to take away from the interaction that happens in those other communities, so as in every other part of OneATS my goal is to make it a seamless conduit for information, regardless of system or user location.
(Jott and Flickr are currently in testing and should roll out soonish…)
It’s also important for us to allow users as much customization as they would like while providing them with a stable building block from which to start. If they can’t trust it and don’t find it useful it won’t be used unless it has to be and everything is forced.
Details and Technology
For those who are interested in the process of creating OneATS and the technology behind it, I wrote it in PHP with XHTML for presentation, CSS for styling and JavaScript (jQuery) for some of the interactive elements and asynchronous content manipulation. All of the data is held within a MySQL database, which was the biggest learning curve for me. I wrote all of the code from the ground up with the exception of two “to be released” modules, the Asbury email connectivity and calendaring modules. Those were written by a co-worker, Jason, in PHP using the SOAP protocol. As far as the design goes, the only part that I didn’t create is the final logo. The amazing introductory video was created by Paul and Daniel, the video guys for the Seminary.
Other Stuff
There are so many details that I could go into about OneATS, the features and the ideas behind it. Probably quite a few articles will be written here based on what I learned from writing it, and I have learned quite a bit since January. We’re also talking about potentially releasing this as an open source project, but we’re uncertain about that so far. I think I’ve written enough about the process, probably boring some of you to tears. Now that things are a bit more calm I’ll be writing more often as well as updating the “photos of the week” section. Well that’s my hope anyway, I also have a redesign of my site as well as some other sites on their way. It’s been a busy couple of months to say the least, but they’ve been a ton of fun.
Share on Twitter | Share on Facebook | Bookmark on Delicious |
Comments
Jun 23, 08:16 PM
Leslie: Sorry for the delay there, I was on vacation for a few days without an Internet connection. To answer your question, it really depends on which use of RSS feeds you’re meaning. In our case users can both read and produce RSS feeds from within the system. To bring data into the system, chances are that if the RSS feed is formatted differently than expected it will just break or look funny when displayed. But if somehow you could trick the feed reader into pulling in some code it might do something adversely. Of course, it would be difficult to get that code injected unless of course you were someone like CNN or a malicious user with a way to indirectly hack using generated XML. I have my doubts but I wouldn’t say it’s impossible without further research.
If you are asking about the syndicated feeds from the site, those are viewed by the user as “pulled information.” So the only place the person would come in contact with the information is on their feed reader (browser included). The syndication mechanism I wrote isn’t looking for data to be inserted and so I’d say that getting it to pull anything into the rest of the portal is a long shot. But again, somehow it might be possible.
I have been asked if I wrote for the New York Times before, but unfortunately it’s just a guy with the same name… or a doppleganger. …If anyone from the NYT is listening, I’m available. Hint hint…






Leslie
Jun 21, 02:59 PM
Does including RSS feed options open up the site to security vulnerabilities?
For a split second I thought you started writing for the NY Times.
http://www.nytimes.com/2008/06/20/opinion/20brooks.html?em&ex=1214193600&en=00c95f8ea46a7c37&ei=5087%0A
(you have disabled html tags :P I would’ve linked it for ya!)