This project was completed for 6.170, part of the MIT EECS curriculum. The main website is accessible here.

The gauntlet had been thrown: to be tasked with creating a complete Java application while thrown into a group where all previous work was individual. In this document, we will attempt to demonstrate what we have been doing during the six week development time, starting with the basic goals we layed out which evolved over time. Organization is chronological, in hopes that our rationales for decisions will be logically understandable. Object models / basic module dependency diagrams / testing strategy are included at appropriate timesteps.

The Brainstorm (october 30, 2006 - November 1, 2006)
Initial goals
We narrowed down the highest level goals to the following three objectives:
1. Streamlined user interface.
2. Extensive developer interface for loading views at runtime.
3. Modular, compact classes with listener / event framework for maximum independence.
Each goal is outlined in detail below.

User Interface
We decided to base our philosophy on making basic tasks a two-click process. These things included creating new views for a feed, manipulating through different views, closing views, and changing views. We noted that a tab-based structure would fit quite well.

Tabs provided the double benefit of being able to cycle through multiple panels with a single click while being able to view what other panels are available. We had not quite came up with how to address creating a feed with a two-click process or manipulating through different views yet, but we decided to outline the categorical goals formally.

1. Responsive. We believed an active, responsive user interface provided the user the illusion of a continuous stream of content rather than a torrent of information occuring at stochastic intervals
2. Minimize clutter. We believed simplicity was key, to ensure all items in our menus and toolbars were necessary. No more, no less.
3. Look pretty. We believed an aesthetically pleasing interface induces the user to use its interface. We were not quite sure what comprised of a pretty interface yet and what was possible with the platform we were designing on.

From the start, we decided to go with SWT for our graphical engine. After hearing the testimonies of previous groups and general impression of providing a nicer looking interface, our minds were made up. This proved to be rather fortunate, as we found out the wealth not only lied in the appearance of the interface but in the extensibility with custom controls.

Developer Interface
As the theme this year for 6.170 is focused on views, we though it would be rather cool to have live plug-ins. Akin to what we had for Firefox or Internet Explorer, the ability to download new plug-ins from the web and load it up directly from the compiled program seemed like a powerful solution.

In examining feasibility, we drew a few conclusions:
1. We would need a strong view interface that would provide enough freedom for developers to spin their creativity, while at the same time creating a standard set of methods for the gui to control.
2. We needed a feedback system for the view to communicate with the gui. As a Java interface could not be the answer for this, we were put in a minor dilemma. The solution came later on relating to the listener / event framework.
3. Inside the views, users should be able to mark things as read or save things for later.

The command / reponse system was puzzling, as it seemed like it was a fine line between dictating what views can or cannot do along with being able to harness the controls with standard actions. Also a point of great debate was concerning how these views should be related to the tab structure we had decided for the user interface. Should the developer be responsible for an entire tab? Should views return a tab? Should the gui provide a tab for developers to fill it up with? Our meeting notes were filled with unanswered questions.

Karl was an expert on listener / event systems, as he expertly demonstrated in his Problem Set 6. He taught the rest of us until we understood what exactly was the rationale behind it. What it provided was the basis for asynchronous message passing. Whereas traditional the method call / return required a single thread to carry the operation through completion, listener / event systems provided the response could come whenever the operation completed, without the caller having to wait for it.

Say Bar needs something from Foo. Instead of calling a method that provides a return variable, Bar simply calls a public method in Foo and forgets about it. Foo carries out the operation and when it has completed, it puts the result in a new FooClassEvent which is sent to FooClassListeners. Important thing to note is that FooClassListeners contacts BarClass, FooBarClass and FubarClass all at the same time. Bar is happy as it has received it's result and doesn't have to wait for it. We have the added benefit of being able to contact FooBar and Fubar on the side without having to make specific method calls in FooClass or BarClass.

But wait, Karl made a dramatic pause, here's the biggest benefit of all: notice the fact that Foo never calls a Bar / FooBar / Fubar method directly. For all we care they may have drastically different signature names and everything will still work fine. Conversely, even if FooClass was replaced by a completely different implementation, as long as it could launch the same FooClassEvents, the rest of the project would be safe.

Ah, we murmured in agreement, and this became our central working structure as evident in our final dependency diagram shown below.

Click on image for larger version

If you examine the diagram closely enough, they say it passes a resemblance of a monkey. The structure will be discussed more in detail in the following segments. For now, note the three main listener / event models: GUI, View and Data. (This is appropriately right in the jugular as the three comprise the neck.) Controller is the supreme class which can call GUI, View, and DataSource public methods. In order for the GUI, View and DataSource to respond, they must rely on their GUIEvent, ViewEvent, and DataEvent respectively. (Which comprise the torso and the legs.)

The Preliminary (November 1, 2006 - November 6, 2006)
Initial Task Assignments
We divvied up the assignments according to what each of us had most experience with. Karl naturally took charge of the Controller design, Lydia had experience with databases, and I (Jong-Moon) who has always been fascinated with user interface designs took the gui lead. We also assigned secondary responsibilities of an area of exploration. Karl would check out Rome for RSS parsing, Lydia would look into LSA parsing for something we might be able to use for one of our views, and yours truly explored custom swt ui elements to improve our lives.

Abstract Data Types
Hold up! Before we got carried too far, we decided to write up the abstract data types for feeds, feedItems, and folders first before splitting up to do our own components. We reasoned nearly every class will touch the adt's sometime or another.

Nice, simple, straightforward. Folders will contain Feeds which will contain FeedItems. This was very similar to the final object model we ended up with which is shown below.

The differences occur as we decided that folders may contain other folders. In order to account for that we created TreeFolders which may contain other TreeFolders and Feeds. RootFolder is a type of TreeFolder which is not contained by anything else. With our ADT ready to go, we plowed ahead and explored our various topics.

Here are the things we have discovered after our first venturing session:
Karl - Rome's documentation can use improvement, nevertheless the code is clear and we should be able to figure out a way to implement this. He also found some resources for linking up jars live at run-time that he will further look at.
Lydia - Looked at each of the suggested database libraries, found Derby to be most complete, but worried of some testimonies that Derby single-handedly ruined somebody's project in the past. We got some conflicting opinions, we hoped for the best and decided to use Derby.
Jong - Swing pales in comparison to what SWT can produce graphically. With built in menus, toolbars, popup menus and a whole host of other widgets, SWT is definitely the way to go. Discovered CTabFolder which produces Eclipse-style 'fancy' tabs. Raised a ruckus of how awesome it will look like.

First Deliverable
This is how Monkey RSS looked circa-first deliverable.

Click on image for larger version

We were in high spirits coming out of our preliminary release meeting with Lucy (our awesome TA). We had the basic layout already set up with the tree to the left, tabs to the right with parsing development well underway. Lydia had gotten started with developing our RSS suite for storing and getting back Feed information.

The Secondary (November 6, 2006 - November 22, 2006)
We hit a nasty bit of snags right after our primary release. The CVS implementation in Eclipse is clunky, which caused us problems with updating and committing. In particular, our Core gui file was somehow forked, causing Karl and I to be working on two different versions of the GUI. Figuring out who did what change and how to resolve that was a big headache. (Note to future 170 students: do NOT use forking. Simply do not commit changes until you can update and see no errors. If all else fails, deleting the source file and 'Restore from repository' is your friend.

It turns out Derby is not as straightforward as we thought it was. It seems that Derby had not been implemented with completely adhering to the SQL standard. Lydia is having some difficulty in figuring out which functions are implemented in Derby and which are not.

In retrospect, not as much work was being done during this time. Exploring through brand new libraries for the first time takes a great load of patience and willingness to put the time into searching obscure forums for answers to obscure problems. It is much less programming skill as it is a puzzle hunt.

As for me, the swt layout was giving me trouble. In order to implement the intricate interface design we were planning, it required quite a fair deal of special layout. The given GridLayout and FormLayout seemed insufficient to make it happen.

New DisCoveries
During the following two weeks, we made a few discoveries that renewed our pace into attempting to implement the elements we need.

Karl has figured out how to work Rome and now we are able to parse RSS 1.0, 2.0 and Atom with ease. He has discovered a built-in SWT widget that lets a browser window be placed inside a shell. He decides to explore how to figure out outputting the RSS feeds in basic form.

I have discovered a magical layout form called MiG Layout like most custom made SWT components, the documentation is spotty with no direct javadocs provided. I proceed to hack around the given demo layouts to extract an element suited for our purpose. It is also around this time that I come around to the idea of having a pop-up menu when feed items are clicked upon to select which view is necessary. I felt like it was the perfect solution for opening up views efficiently. Karl disagreed, pointing out the fact that it would hamper drag-and-drop and other tree / mouse related activities. We agreed to test it out first and then make a decision.

I had absolutely no idea how I would implement just a pop up at the time. I didn't even know it was possible, as all I had seen were regular dialog boxes. Originally, the aim was to create a semitransparent popup with scrolls at the side to navigate through the available views. More on the popup evolution later.

Lydia discovered a live database input prompt that allowed real time query of the database. This let us try out SQL commands to see what Derby can do and cannot do.

WIth the amendment out concerning multiple users, we decided that this would most easily be solved on the database level. The database would be responsible for reflecting the state of multiple users and storing all of their information.

SECOND Deliverable
This is our view that we supplied. Karl cooked up a simple HTML view that would generate HTML given a Feed and dispaly it inside a SWT browser widget. Very cool. (Note: at this time, we did not have the 'Mark As Read' check box)

We had a temporary fix on the database using a HashTable to mimic a database. This was useful while Lydia could finish the database. We knew we had fallen behind of what our schedule dictated. Closing into Thanksgiving weekend, we realized we had one more week before the final project is due. Never had deadlines came up so quickly.

Thanksgiving Break
I had gone home for Thanksgiving while my two compatriots were back on campus. Unforunately I don't know in detail of the special discoveries made during this time. Karl made the Newspaper view during this time. On the plane ride back, I knew we were in for a difficult week.

The Cram (November 22, 2006 - December 4, 2006)
Ramping up
I am not sure what allowed us to quickly ramp us up in speed in development. Perhaps it was that we had gotten use to the libraries to become fluent in the semantics. I now had SWT layout code coming out of my ears as I could soon tell what it would look like without ever having to compile it.

The base layout was entirely done. In the midst of my rapid fire figuring, I noticed we could have vertical toolbars. I suggested that we place views inside toolbars on the right to be used for switching between different views. My teammates agreed and we arrived upon what would be our final base layout.

Karl had now moved onto integrating the Control structure, trying to figure out how exactly to get response from a browser widget. The problem with having a browser in a view was the fact it was not a SWT button. There was no direct way to attach a listener to an HTML link. He figured out a rather clever way of linking the 'Mark As Read' links to a specific "fid://" protocol and capture the event using the browser's LocationListener. We now have a second fully functional view.

It is durnig this time I use my photoshop and graphic design skills to produce some icons. I attempted to make these look as professional as possible, making them look obvious to what purpose each serve.

Lydia is now generating test cases to ensure the database is entirely correct upon integration. The week goes by quickly.

T-Minus THree... TWo...
It is Friday afternoon. We have two days left and we are unsure if we can make it. We are determined and armed with 85% cocoa wake-you-right-up chocolate bars. Let's dance.

I started off by helping Karl fix up the Newspaper view. We CSS stylized it and javascripted hiding actions to make the user experience all the more interactive and lively. Below is a sample of what we came up with.

Notice each story folds and compacts as soon as a story is read, opening up space for articles below. We thought this looked spiffy. Heartened, we quickly moved onto other components. Karl started work on the FTP / SSH / TFTP protocol exporting while I worked on creating a mailbox view. Below is what I ended up with.

I had some definite Thunderbird inspiration guding me in the creation of the view. It is a fully featured Feed view that allows items to be set as read or unread, sorted by which ever column of choice, and the ability to view only read or unread items. Lydia had finished all the basic database functionality. Now for the amendment items. We worked late into the night and went home to take a nap in the early morning.

We discovered that Athena had been down for the last six hours. Luckily, that resulted in a one day extension for us. Undaunted, we resumed working with what we had locally downloaded. We now entered discussions concerning how exactly we wanted to do the "Read more" links. At the moment, the links were simply being opened inside their small browser widget boxes. We decided that what would make the interface most sleek would be to have a built-in browser to open up as a new tab with the destination link inside. This time, with Opera as my guiding light, this is what I ended up with with the BrowserView.

Even in the midst of the cram, we decided that we should be complete for the sake of quality. What was created was a fully-featured browser view that allowed web viewing with standard browser functions, complete with shortcut keys. (Alt + left, Alt + right, f5, ctrl + r, backspace) In attempting to locate a spot for the progressbar, we were stumped. Karl jokingly challenged me to make a Opera / Safari style progressbar, as in the ones where the AddressBar itself is a progress bar. Little did he know I rarely turn down a challenge lying down. It required all bits of trickery and hacking, but that blue bar you see above is animated.

This is the status bar when fully loaded. Lydia was chugging out the test cases and adding the interfaces for implementing a user and an outbox. Karl, finished with FTP loadding, started working on live JAR file importing with the views I had made. I started creating all the dialog boxes that were necessary for Add and Remove users, folders, items and the like.

It started snowing at around 6 am. This uplifted our moods. The first snow of the season! We couldn't wait to get this project finished. It was around 9 am on Sunday morning Karl and I trudged home after agreeing to meet back at 2 pm for the final stretch.

T-Minus One...
We resumed our work diligently, finishing off each component by component. What made making the views so easy was partially the fact the live jar interface now had been completed. I could now load up the main core without worry even if one of the views did not work. Lydia and I worked on our final view called the Happiness view. Using Lydia's exploration of the LSA engine, we hacked together an engine that was quite a feat! We used Java to call our php script which would act like a browser, sending header and feed item encoded as a GET form to the University of Colorado''s LSA parser. The php would then create an html file on a server which we would grab using our program. We managed to get the entire process down to around fifteen seconds. What we get is the top ten feed items of a feed arranged in order of 'happiness' as determined by LSA.

We realized we were deficient of an Outbox user interface where the user would be able to add and delete feed items and grab feed items from other feeds. With all the experience we gained through plowing through the obscure libraries and examples, we managed to get a nice interface at the end of two hours. We took the mailbox view and converted it into an outbox view. Even in a rush, we found a unique solution that provided a live preview of html while the user was tying information in.

This proved to be a neat feature but a needless distraction as we were being entertained only by how live previewed html code can. We rushed to finish up the documentation and test cases for the delivery.

When we were finished, we were spent. Drained and sleep deprived, we head to our homes for some sleep before finish up the post-mortem of what happened with the project.


We will first evaluate the main features of this software then move on to the design philosophy, of how our goals were met (or not met) and what we thought of the experience in general.

Feature Evaluation
First we start off with the Core GUI features that are included.
1. The ability to have multiple users with their own RSS Feeds and Outbox Feeds. Can add, change and delete users in runtime. Processes are extremely quick.
2. The ability to import / export the contents of a user's RSS Feeds. This provides a rapid method of transferring feed data between users.
3. Feed items and folders display the number read which is updated as the user reads items from views.
4 . Streamlined new view interface where new views are literally created with two clicks, usually in less than a second.
5 . Streamlined change view interface where existing views can be changed into any view desired with a single click.
6. Minimalized menu. Four items in main menu, all very concise and to the point.
7. Tree interface provides contextual menu for quick addition of elements.
8. Drag-and-drop is fully supported, allows any valid action directly using the tree.
9. The ability to update one feed or all feeds, where the update processing all occurs in a separate thread. The interface is exteremely responsive even when updating.
10. Caching of text data on hard drive. Even while offline, the feed items display fine for the user to read and enjoy.
11. The screen size ratio between the tree and view are easily configurable for optimum viewing.
12. The window can be shrunk to a great degree before it begins to get cut off.
13. When updating, if existing items were mark as read, they stay read when updated.
14. The icons are designed to look professional and aesthetically pleasing.

General View Features
1. Views are loaded runtime with .jar files inside the 'views' folder. This allows for easy addition and removal of custom views the user may wish to get.
2. Views are loaded in tab structure to facilitate easy transfer between different views. Tab items have 'cool' tab shapes. If there are more tabs than the screen size, it provides an interface to grab the views that were cut off.
3. Views cannot affect the layout of rest of the gui. The gui is protected so if the view expands further than the space given, it renders scrollBars.

Newspaper View Features
1. Three column based design, lists most recent stories on top then proceeds to further back. Items that are mark as read automatically gray out and compact away, leaving valuable real estate for other articles.
2. Read more link leads to a browser link opening to the domain of the site.
3. 'Outbox It' provides a direct link to copy the feed item into your outbox of choice.
4. Nice clean layout for viewing a handful at a time, before scrolldown.

Outbox View Features
1.Can sort by title, author, date / filter out all read or unread from outbox.
2. By clicking on the blue button, the read / unread state can be chosen readily.
3. The blue button can be swtichted exteremly rapidly with no breaking.
4. When using keyboard to navigate selection, only marks it as read if the cursor hovers over in for two seconds.
5. Unread items are bolded to aid clear differentiation between bolded and non-bolded items.
6. Enclosures are handly placed in the footer. If a feed item has enclosures, a user my click under there on the paper clitp to download the enclosure directly
7. This should provide a very familiar interface for Thunderbird users.

Browser View Features
1. Fully featured browser tab built in program that captures any outgoing links from other views.
2. Back, Forward, Stop, Go, Refresh fully implemented.
3. Common shortcuts are added to give consistency.
4. Browser bar doubles in as progressbar, providing a cool view.

Happiness View Features
1. Full LSA analysis on the top 10 feed items in the feed selected. Arranges in order of happiness rating of feed item.
2. Done by connecting to University of Colorado's LSA site to spoof a http request using php then retrieving that using Java.
3. Yields entertaining results!

Outbox View Features
1. Live HTML preview occurs right next to the HTML editor. It's you get what you see on steroids!
2. We can look at any regular RSS Feed to grab items to put into our outbox.
3. We can add our own outbox article, modify, and delete.
4. With our outbox articles, we can publish them using FTP, SSH, or TFTP.
5. Previous hosts are listed to streamline subsequent publishing.
6. Once published, we can subscribe to our own outbox feed and view it! Adding another item and publishing it allows our subscription to update it.
7. The outbox feed retains the property of an outbox feed even after publishing! This means you can edit other outbox feeds published on the net.

Design Evaluation
Listener / Event framework
1. Framework provided a robust, extremely resilient core to fall back upon. Drastic changes to classes that implemented this was no sweat as integration was a breeze.
2. Such framework allowed us to provide efficient threading to keep a extremely responsive interface that should never hang under any circumstances.
3. Addition of new events and expandability is no problem as creation of new events does not require signature modification.

Developer JAR / Strong view interface
1. Quite the testament as we completed four views in two days where time necessary for integration with gui was minimal. We'll have to say this was one of the best features that we experienced first-hand. This made development so much easier.
2. Strong connection with views allows for real-time update of read items and unread items, updating the count live for a responsive environment.
3. As all views need to return is a single SWT composite for the contents of a tab, the possibilities are endless, allowing a developer the repertoire of designing any kind of SWT application, whether it be browser based or not.
4.Easier to stay relevant and nice to be able to download new views from website.

Abstract Data Type
1. Simple and strong, the adt proved resilient through the rigors.
2. Making it simple allowed us to keep it intuitive and easy to understand code during development.
3. Accounted for making high speed development possible.

This was a very enjoyable, albeit exhausting project. We are all very much proud of what we were able to produce. Quite the unique experience of working in a group setting under some pressure. We hope everybody can see the joy that went into our product. We tried to keep things unconventional to make it straightforward. At first it may sound counter-intuitive, but we tried to use creative uses of the user interface to make the experience as pleasant as possible. A nice way to end 6.170. Cheers. :o)



home   |   download   |   final design document   |   documentation
2006 Jong-Moon Kim, Lydia Chilton, Karl Rieb