Typical student projects, e.g. final-year and MSc projects, are a special kind of software project whose development follows well-known patterns: the final document produced is a dissertation with certain standard chapters, the deadline is known, the planning process always involves a supervisor, and so on.
The goal of this project is to create a CASE tool that helps students to carry out their final-year or MSc projects, for example by providing a facility for choosing a software process model (as mentioned above), scheduling the activities, controlling the progress, producing the documentation, and putting all documentation and code together into a thesis in WORD or LaTeX.
(Peter Denning, ACM President, 1982)
Since Peter Denning wrote these words more that 20 years ago, the problem has become even worse. Many people, IT professionals in particular, waste a lot of time coping with unprecedented amounts of email. The problem is not only spam. Every day, there are many important emails which have to be archived or imply new duties with tricky deadlines. Old messages often need to be retrieved. The time wasted by email is a serious problem for companies; Microsoft, for example, produced this article.
The project I suggest is concerned with a mechanism to improve email archiving: views. A "view" in an email client is a criterion for selecting the visible messages (see e.g. views in Outlook, Mozilla). A view is essentially the same as a search which has been stored for re-use. (In fact, I think a view should be precisely that!) Views are a great, because they eliminate the users' need to sort messages into folders. In particular, this eliminates the danger of misfiling messages. (This is also the philosophy behind Google's GMail - "search, don't sort".)
Many email clients do not support views, but even those that do (e.g. Outlook, Mozilla, Ximian Evolution, Columba) suffer from the problem that new views cannot be built from existing ones.
The goal of this project is to build a graphical email client that allows the user to not only create views like "sender is John", but also build views from other views by using logical connectives like "and", "or", "not". For example, consider the following definitions of views:
There should be a convenient way for users to create, edit, and invoke views.
Good work on this project has already been done by the former MSc student Yuen Chan. The idea now is to refine that work and design an graphical user interface that appeals to typical users.
Pre-requisite knowledge: good programming skills (the use of Java is very likely)
Indicative reading: starting points are
Proof-nets are a user-friendly way to present logical proofs in graphical form. In 2004, our MSc student Yifan Xie wrote a convincing editor that allows the user to create and validate such proof-nets.
However, there are still desirable features left to implement: most importantly, the possibility to simplify proof-nets automatically; but also an undo function, and the possibility to print the proof-nets in publishable form.
The goal of this project is to add some of these features, building on the code of Yifan Xie. (The code is in good shape.)
Pre-requisite knowledge: a student undertaking this project should have enjoyed the more mathematical courses offered in computer science and - in particular, `COMP0019: Computation III: Introduction to Formal Logic and Semantics' - and should be planning to take 'CM30071: Application of Logic'. The project also requires good programming skills, basic knowledge of parsing, and an interest in the design of graphical user-interfaces.
For example, there may be classes called:
There should be features like "load game", "save game", "undo move", and the possibility to let the computer play against itself (using two different strategies). An optional feature would be the implementation of an optimal strategy for ANY game that assigns scores to board situation. This could be implemented by a technique called "alpha-beta search" (also "minimax search").
The usefulness of the API should be demonstrated by using it to implement at least three SIMPLE games, like Tic-Tac-Toe or Connect-Four. The point is to demonstrate that your API nicely captures the common elements of board games, and any Java programmer who is interested in implementing a board game would have an easier time if they used your API.
Pre-requisite knowledge: This project requires an very good understanding of object-oriented programming, and Java in particular, because the code you produce is not aimed at end-users, but at PROGRAMMERS who build on it.
Indicative reading: To get an idea of alpha-beta search, look at . this website
I am interested in learning software that makes it easier for students understand these topics. For example, one could produce a simulator that allows the user to enter a program for an abacus machine and then visualizes the program execution. Or similarly for Turing machines or recursive functions.
Optimally, such a teaching tool should encourage students to experiment, and thereby learn in a playful way.
Pre-requisite knowledge: good programming skills, basic knowledge of parsing, interest in designing graphical user interfaces.
Most mobile phones have a reduced keyboard: each numeric key corresponds to three or four letters. This makes it hard to enter text, because it is not clear which letter the user wants when they type a key. Phones with predictive text guess the word based on the numeric sequence entered by the user, based on a dictionary, the technical term for which is corpus. In fact, from any text (e.g. a newspaper or one's personal diary), one can create a prediction algorithm that "knows" all words in that text.
For some number sequences, there will be more than one word (e.g. "me" and "of" for 63). Apparently, these annoying ambiguities depend on the key assignment (i.e. the assignment of letters to digits). For example, if all vowels were assigned to 1 and all consonants to 2, then "me" would correspond to 21 and "of" to 12 - there is no ambiguity. The standard key assignment surely causes unnecessarily many ambiguities, because it fails to exploit the frequency and order of letters in English language.
The goal of this project is to improve reduced keyboards, by changing the assignments of letters to numeric keys. (We consider a reduced keyboard X better than a reduced keyboard Y with respect to a text T if the user can enter T on X faster than on Y.)
The quality of a keyboard depends not only on its ambiguity. It also matters, for example, how much the user has to move their finger(s).
One way to find better keyboards is an evolutionary algorithm that gradually changes the reduced keyboard and re-calculates the time needed for entering a text; better keyboards are kept, worse keyboards discarded. After some large number of steps, one should have a keyboard that is significantly better than the standard one. A possible approach to this project is to design such an evolutionary algorithm and experiment with it.
Pre-requisite knowledge: students undertaking this project should be comfortable with programming and basic statistics.
Indicative reading: the article Corpus-based stochastic finite-state predictive text entry for reduced keyboards: application to Catalan by Mikel L. Forcada is a good introduction to the subject.