Fennec Browser

Create a basic web browser like Firefox, Safari, Chrome, Opera, Camino, or Internet Explorer. Although this may sound like a difficult task, the Java Swing package is shipped with all the necessary classes to build a simple browser easily. Additionally, you do not need to support viewing complex web pages that contain forms, active scripts, or style sheets; instead, you should concentrate on making the user interface you provide the user to do basic browsing tasks as flexible as possible.

Specification

Write a web browser that allows users to locate, view, and manage web pages interactively. The browser should support displaying multiple web pages at once either in a single window (via tabbed browsing), multiple separate windows, or a combination of both.

As a minimum, your browser should support the following features:

• a home web page that is loaded when the browser creates an empty window/tab
• a history of all previously viewed web pages
• a collection of favorite websites
• save the current web page to a file

Users should be able to access each of these features via both a menu options and one or more toolbar buttons. Users should also be able to customize each of these features by setting appropriate preference options (e.g., change the home page, limit the number of history items saved, choose where to automatically save pages, or clear these collections) that should be retained across multiple uses of the program. Finally, users should able to view the contents of each of these features (i.e., the entire history, the saved files, etc.), either in a separate window, a web page, or a text file.

All other features listed below (and, optionally, the ones above) should be implemented using an add-on (or plug-in) architecture that allows users to turn them on or off dynamically while the program is running. When an add-on is active, any menus, toolbars, or preferences required by it should be available to the user; when it is not, they should be removed from the browser's interface. Users should further be given an interface to manage these add-ons, i.e., to locate, install, or remove them from the program.

The following are example add-on features:

• full-featured URL tool bar (i.e., tries different common URL combinations when given an incomplete URL, completes based on user history, favorites, etc.)
• full-featured favorites manager (i.e., update names of favorites, categorize favorites, remove favorites, etc.)
• full-featured download manager that allows users to download, cancel, or save large files
• provide an error console that logs all errors that occur during browsing
• view the current web page's HTML source code
• view local files in addition to web pages
• view a directory as a list of clickable links
• view a directory of images as a page of thumbnails (or slideshow)
• view the most visited web pages in the user's history or favorites
• view thumbnails of visited pages
• view and manage cookies associated with web pages
• view and manage session data (i.e., multiple pages that load at once, either when the browser is opened or when selected)
• allow smart favorites lists that are created from filters of the user's history
• search a web page for a specific string
• view and manage RSS feeds
• view and manage blogs
• allow users to create profiles to specialize individual browsing sessions
• import bookmarks or history from other commercial browsers
• cache web pages on the files system so that they can be more quickly retrieved in the future
• view other types of MIME formats (i.e., image files, audio files, video files, XML files)
• support social browsing (i.e., allow users to connect with other users using your browser and share web pages or chat)
• allow mouse gestures to be used for generate actions in addition to the provided buttons
• any other features you have always wished your browser had

Finally, the browser should support running Jython scripts that modify the browser. For example, the user could run a script to remove selected entries from the history or favorites collection; or the user could add a button to the toolbar that loads a specific page. Some of the add-on features above could even be written as scripts instead of using Java. Scripts will have complete access to the classes in your browser program, but you should specifically provide a reasonable interface to allow scripts to discover if a specific add-on is installed and get access to it.

Extra Credit

There are many extensions to the basic specifications possible; many are listed above. From the stand point of your grade, the most important thing is that your program is designed well (i.e., that it is possible to add-on new browsing add-ons simply by creating new subclasses and adding O(1) line to your existing code to include the new classes). This means your add-on API should be as clear, concise, and flexible as possible to future developers.

Finally, the add-ons given above are intended to stretch your design further and to differentiate your program from others in order to capture the uber-browser market, your team should agree on three add-ons to focus on if you want to be considered for a grade in the A range. These add-ons must further the good design of your program and not simply be hacks of code added at the last minute. If you do not have time to implement an add-ons, partial extra credit may be given for excellent justification of how your design either supports adding such a feature already or how it would need to changed sufficiently to support such a feature.

However, note that the amount of extra credit will be in proportion to the amount of intellectual effort needed to implement the option. For example, adding an HTML source code viewer is not as much as an RSS viewer because the latter requires extra research and interface design to complete. Of course, a well-tested, perfectly working program that has fewer features (but plenty of clear paths to easy expansion) is always worth more than the leaky kitchen sink.

Your project's model (not its GUI) should be thoroughly tested to prove to the course staff that your confidence in it is justified. You should include whatever data files, unit tests, or other driver programs (as well as documentation on how to use them) you have used to test your program in your submission.

In short, to maximize your grade, you should implement enough variety in your program to clearly demonstrate that your design supports further such add-ons.

Deliverables

0. Sunday, October 26. Team preferences (one submission per person)
   Email Professor Duvall a team of two people with whom you would like to work.
1. Tuesday, October 28. Team design version 0.1 and estimate (one submission per team)
   Submit a README containing the address of your website that contains:
   1. a name for your team's "company"
   2. a description of your team's shared vision of the project (think of this as the advertising blurb on the box in which your software will be sold)
   3. an estimate of how long you expect it to take the team to complete this project; include as specific a task list as possible to support your estimate (i.e., break the project into small sub-problems, each of has an estimate and priority for completion)
   4. a description of the underlying model classes you expect to support the project.
   5. a description of your graphical user interface, including drawn "screen shots" of how you plan to lay out your interface and how you plan to connect the interface to the model.
      
   We will check this page frequently to check on your progress, so you will need to update this web site as you develop your project.
   A former UTA's guide to running your initial design meeting is available online here.
   
2. Sunday, November 2. Program and design version 1.0 (one submission per team)
   Submit a program that, at a minimum, should be able to
   1. navigate through their previously viewed websites using back and forward buttons
   2. set a specific web site as a home page that appears when the browser is started the first time or whenever the user presses the home button
   3. save a specific web site into a set of bookmarks that can be recalled later
   Your web site should include a current version of your programmer documentation that reasonably describes the current implementation.
3. Monday, November 3 --- in-class. Add-On Specification version 1.0 (one submission per team)
   1. an in-class presentation that proposes an API to allow programmers to write add-on functionality to your browser
      Your presentation should include a description of your API, an example of how to use it, and trade-offs inherent in your API in such a way to convince other teams to adopt your API as the class standard. You may also demo your working code, if it makes use of your API, to help your case.
   You will have just 5 minutes for your presentation. Make it professional and well-structured
   Submit your presentation slides (or notes) as well as your demo code.
4. Tuesday, November 11. Submit the final version of program, including all programmer documentation.
5. Friday, November 14. Your individual project analysis is due (one submission per person)