Team Project: Reengineering LAPIS GUI

Background and Motivation

Useful software tends to have a long life after their first releases. Based on their experience with using the software, clients report bugs and request new features. As a result, software development teams must fix bugs and implement new features to support the work of their clients. This kind of practice is called Software Maintenance. It is reported that overall, software maintenance consumes more resources than the initial development. More often than not, a new developer hired by a company would start with some kinds of maintenance oriented tasks. It is a vital skill for a developer to be able to understand code written by others and perform changes according to requirements.

Modern software often has some kind of graphical user interface (GUI) with which clients directly interact. GUI usability can be important to the acceptance and success of a software product. Large firms like Microsoft and IBM often assign dedicated GUI usability teams to test their products throughout the software life cycle. Smaller firms, with less resources, may require individual developers to do both coding and usability testing. Thus, understanding your users and developing usable GUI for them is another valuable skill that a developer should learn and master.

The goal of this project is to reengineer LAPIS in a team of 3 - 4 members. The assumed context is a company that is going to make an official release of LAPIS.  Thus, it becomes necessary to remove from the current version of LAPIS as many as possible usability deficiencies or concerns that may be justified from a research stand point but absolutely unsuitable for a product. Note that this reengineering process does not imply that the LAPIS developers are incompetent. Rather, it shows that dedicated engineering effort for usability must always be planned and conducted in the development of any serious product.

The starting point for this project is a set of requirements described in the next section, which are derived from your efforts in doing Assignment 3. Since this project is a team effort, it pays off for you to think early about work load distribution among team members. Possible roles for team members may include designing & programming, testing & reporting, and demo & presentation. Note that one member may assume multiple roles and one role may use more than one member. Effective communication, cooperation, and coordination are keys to project success.

Product Specification

Part A. Core Functionalities

A1. Main menu (4%)

   - Remove Debug menu and all of its menu items.
   - Move help menu to the far right end of the menu bar.
   - Reorganize the menu bar as follows (change Go to History, and Tools to Commands; move Selection to Edit, and Scripts to Commands).

File   Edit           Commands    History                           Help
           ||                      ||
           =>Selection     => Scripts

    - Make sure that all menu items have accelerator keys.
    - Use ellipsis in menu text wherever necessary.

A2. Command ComboBox (2%)

    Prevent adding into the command history any command that contains a syntax error.

A3. LAPIS Help (2%)

    Display help contents inside the current LAPIS window rather than opening up a new window.

A4. Cleanup (2%)

    Remove the stderr pane below the main text area. Remove the feedback button at the bottom right corner.

A5. Geek Speaking (3%)

    a. When command "extract xyz" is entered into the command field, a dialog with a title "TCParseException" is popped up. This commits blooper 26, speaking geek. Change the title to "Command Syntax Error".

    b. When the following pattern is entered into the pattern area,  a dialog titled "parse error" is popped up. Another example of blooper 26.  Change the title to "Pattern Syntax Error".

             word start with "aaa"
                  ending "bbb"

    c. When the "Send Feedback" button is clicked in the "Send Feedback and Bug Reports" form, a dialog titled "FileNotFoundException" is popped up. This is an example of blooper 28, "Erroneous error messages". Correct it by giving a better title like "Log File for Saving Feedback Cannot Be Found".

A6. Consistency with Mainstream Web Browsers (7%)

a. Move the Back, Forward, Reload, and Stop toolbar buttons to the same row as the command combo box.  Remove the "Command" label from the command combo box. This will make LAPIS similar to IE and FireFox. Feel free to change the icons if desired. 2%

b. Re-implement the pattern editor and the script editor as a dialog. Separate dialog control buttons from content control buttons. Currently, these 2 editors use a combo box to implement common actions like file creation and file saving. Use a menu instead. 3%

c. Re-implement "Find and Replace" and "Clustering Find and Replace" as a dialog as well. 2%

Part B.
Teams may voluntarily implement some of the following features, which are considered more challenging. Bonus marks may be given under the instructor's discretion.

B1. Redesign the patterns dialog by replacing the pattern history with a scrolling list, and adding a button to invoke "Unusual Matches" directly inside the patterns dialog. (Currently "Unusual Matches" is only available as a menu item.)

B2. Currently, the markers are drawn on the track of the scroll bar in the main text area. Show colored markers on a separate column, in the same way as Eclipse does in its Java editor.

B3. Sometimes, LAPIS displayed a web page as "Plain Text". This is a poor default. Correct it so that the right file type is used.

B4. File history versus command history. A web browser maintains, in temporal order, a linked list of documents (navigation history) that a client has visited, as well as all the documents a client has seen (history). History always subsumes, but may be **strictly** a super set of, navigation history. The command history of LAPIS, as is, is effectively identical to this web browser history model. On the other hand, a true command history will provide, for each document visited, a list of commands that once executed in order, will lead to the creation of that document. Such a command history can then be turned into scripts and reused in the future.

B5. Anything that you would like to try out as part of the project. Must be approved by the instructor to qualify for bonus.

Peer Testing

In addition to reengineering LAPIS, each team will also test another peer team's product anonymously and produce a testing report. Teams must email me a URL where their final product can be downloaded and tested.


Due Date & Deliverables

Tuesday December 2:
6 PM         Working Software uploaded to a given URL for peer testing

Wednesday December 3:
4-5 PM      Demo & Presentation
                 15 minutes per team

Friday December 5:
11:59 PM  email me the following items in a zipped file
                 Testing Report + Development Report + Final Project Source Code


*** Extension of any due date can be purchased at the price of 5 marks per 24 hours.


Marking Criteria

30% (20% core functionality, 6% development report (3) & demo and presentation (3), 4% testing report)

1. Core functionalities (20, see the Product Specification section for detailed mark breakdown)
 For each core feature implemented, the following percentage of marks will be given
    - 100%, absent of bugs,
    - 50%, some bugs but able to work around them,
    - 0%, otherwise.

2. Coding style
   - It should be relatively easy for me to identify what changes you have made to the LAPIS source code. This can be achieved by appropriate comments for important methods and data structure in the source code plus a note in the development report. You may lose up to 20% of your mark for poor coding style.

3. Demo & presentation (3)
   - A team will get 3 marks automatically if they demonstrate their program and speak about their major design decisions before the class.

4. Development Report (3)
    A short report (no more than 3 pages) that describes
   - team member work distribution (1)
   - what have been implemented and where they can be found in the source code (1)
   - lessons learned (e.g., team work, development process, technology) (1)

5. Testing Report (4)
A list of problems you identified from the software you tested and a description where and why they are problematic. The description should be clear and easy to understand by the development team and me. Use screenshots. Your report will be given a grade using the following formula, min(1, m/n)*4, where m is the number of problems that you correctly identified, and n is the number of problems that the instructor identified from the final product.

Tips:

Technical tips may be posted here during the next 3 weeks.